流程一拉長，AI 每一步都像剛回到座位的人

前一天用手動交接測試一件工作該不該拆，最後留下一張交接單和三個問題，這張單子要放在哪裡、由誰更新、流程中途斷掉時要怎麼接回去。三個問題背後是同一件事。工作流只有兩三步的時候，prompt 寫得好不好幾乎決定了結果，流程拉長到七八步、跨好幾天、中間還要等人確認，決定結果對不對的就換成另一件事，每走完一步之後，有沒有一份紀錄說清楚「現在進行到哪裡」。這份紀錄在工程上叫做 state，中文叫狀態。

休假一週回到公司的早上，多數人都經歷過。信箱裡躺著幾百封信，最先想知道的不是每一封寫了什麼，而是哪些事已經有人處理掉、哪些還在等自己、代理人有沒有替自己答應了什麼。把幾百封信從頭讀一遍也拼得出答案，只是又慢又容易漏，代理人留下的一張進度清單，反而幾分鐘就能讓人接上手。

AI 在長流程裡的每一步都面對同樣的處境，而且更徹底。每一個新的工作階段開始時，AI 對先前發生的事沒有任何記憶，就像一個輪班制的團隊，每位新來的成員都不記得上一班做了什麼。人休假回來至少還記得出發前在忙什麼，AI 換一個對話，連這一點都不會留下。

Prompt 都沒寫錯，長流程還是會在三個地方出事

延續前一天的客戶提案。整條線拉長之後是查資料、彙整往來紀錄、寫初稿、主管確認、排簡報、寄出，橫跨三四天，中間還會被其他會議和信件打斷好幾次。

三種情況的 prompt 都沒有寫錯，每一步也都照著指令執行。出問題的地方在於整條線沒有一個位置記著現在走到哪裡、哪些已經算數，每一步只能從當下看得到的對話去推測前面發生過什麼，推測錯了，後面就跟著錯。

AI 一次能攤開的資料有上限

第一種情況最常被誤會成 AI 不夠聰明，問題出在它一次能看的範圍。AI 處理一段對話，就像把所有資料攤在一張桌子上工作，桌上攤開的這些內容就是常聽到的 context，中文叫上下文，而這張桌子再大也有邊。對話一路拉長，桌面堆滿之後，工具通常會把前面的內容收成一份摘要，騰出空間繼續做。摘要寫得再好也是濃縮過的版本，信串中間那句「客戶拒絕過方案 B」，很可能就在這一步被省略。

桌面還沒堆滿之前也不輕鬆。放進來的內容越多，AI 準確想起其中某一段的能力就越下降，上下文因此是一種有限、而且越用越不划算的資源。就像桌上的文件越堆越高，要找出三天前那張便條就越難，跟做事的人認不認真無關。常見的解法之一，是讓 AI 定期把重點記到桌面以外的地方，需要時再拿回來，這和後面要談的狀態卡是同一個想法。

斷掉的時候，從頭重跑反而最危險

先猜一題，工作流跑到一半斷掉，最安全的做法是不是把整條流程從頭再跑一次？

答案剛好相反。從頭重跑看起來最乾淨，卻可能把已經寄出的信再寄一次、把有人改過的版本蓋掉，也讓已經定案的判斷重新交給 AI 決定一遍。重新開始的代價高，也讓使用的人挫折，比較穩的設計是讓系統從出錯當下的位置繼續，並且在對話長度超過上限、內容被截斷之前，先把計畫存到對話外面。能從斷點接回去有一個前提，就是對話之外有一份紀錄記著斷點在哪裡。

不想每次重講的東西，依變動速度放在三個地方

新人到職要接上手，通常靠三樣東西。部門的作業手冊告訴他這類事情該怎麼做，跟主管相處一陣子之後慢慢知道對方的習慣，手上接到的專案則有一份進度表。三樣東西變動的速度差很多，所以從來不會寫在同一張紙上，作業手冊一年改一兩次，主管的習慣要幾個月才摸得清，進度表每天都在變。

AI 的工作流也是同樣的道理。前一天那張交接單如果什麼都往裡面塞，很快就會變成一份沒人想讀的長文件，比較好的做法是依照變動速度分開放。

要判斷一句話該放哪裡，問兩個問題就夠了。先問明天會不會變，會變的放進狀態卡。不會變的再問它跟這類工作有關，還是跟這個人有關，前者寫進工作說明書，後者交給記憶。

依變動速度分開放，還有一個不太被注意的好處，跟 AI 工具背後的快取（cache）有關。同一段開頭如果每次都一模一樣，系統可以直接沿用上一次已經讀過的部分，不必從頭再讀一遍，回應比較快，成本也比較低。所以固定不變的說明適合放在最前面，會變動的內容放在最後，因為只要前面有一個字不同，後面就得全部重新讀過。這就像每次開會都發同一份講義，與會者翻到熟悉的頁面就能略過，有人在第一頁插進今天的進度，整份講義就得從頭看起。

一般在聊天視窗裡碰不到這些設定，順序的道理卻一樣適用，工作說明書放前面、狀態卡放後面，也正好是後面範例的排法。要留意的是快取通常只保留幾分鐘，它省下的是重讀的時間，不會讓 AI 記得這件工作做到哪裡，該記的進度還是要寫在狀態卡上。

各家工具對前兩樣的叫法不同。VS Code 裡的 GitHub Copilot 可以把常用的任務寫成副檔名為 .prompt.md 的 prompt file，在對話框輸入斜線加上名稱就能叫出來，另外還有自動套用到每一次請求的自訂指令。Claude Code 每次開始時會讀取人寫的 CLAUDE.md，也會載入它依照使用者的修正自己記下的自動記憶。Microsoft 365 Copilot 則有使用者明確要求保存的記憶、從對話歷史推斷出的細節，以及自訂指令。名稱各不相同，做的都是同一件事，把不想每次重講的東西搬到對話外面。

有了記憶功能，狀態卡還是要自己留

AI 已經會記得使用者說過的話，很容易讓人以為進度也可以交給它記。記憶擅長的是這個人偏好什麼、習慣怎麼做，不擅長記住這件工作的第三步有沒有人確認過。Microsoft 365 Copilot 從對話歷史得到的細節是動態的，較舊的內容可能被更新或捨棄，Claude Code 也把人寫的說明與自動記憶當成參考的上下文，不是強制執行的設定。

偏好被淡忘了，頂多是報告又先寫了背景才講結論。已經定案的事被淡忘了，就是那個被拒絕過的方案又回到提案裡。需要精確、需要事後查證的東西，要放在人看得到、改得到、也找得回來的地方，這就是狀態卡存在的理由。

狀態卡記五件事，前一天的三個問題一起回答

狀態卡不需要專門的系統，一份共用文件或一張表格就能開始。把前一天交接單上的欄位搬過來，再補上誰確認過和什麼叫做完，就是一張夠用的狀態卡。

把這張卡放在對話之外、人和 AI 都打得開的地方，第一個問題就有了答案。第二個問題看的是誰能改哪一欄，AI 可以推進「做到哪一步」、補上「依據在哪裡」，也可以在「還懸著的事」提出新的疑問，「已經定案的事」則只能由人寫入。第三個問題的答案就在卡上的第一欄，新的對話從那一欄記下的位置繼續，已經完成的部分不再重做。

控制狀態的三個規矩

有了狀態卡，還要讓流程裡的每一步都照規矩對待它，否則它很快就會變成另一份沒人更新的文件。

第一個規矩是開工先讀、收工先寫。每次開工先讀進度紀錄，收工前寫下這次做了什麼並更新進度，下一個接手的人或 AI 就不必從頭摸索。

第二個規矩是把停下來的條件寫在卡上。什麼情況 AI 可以直接往下走、什麼情況要停下來找人確認，事先寫清楚，不留給 AI 在當下自己判斷。這條界線守住了，長流程前面那些關鍵判斷就不會在第五步、第六步被悄悄改寫。

第三個規矩是完成要對照清單。開工前先列出一份完整的清單，每一項一開始都標成未完成，AI 只能改動每一項的完成狀態，不能自行刪改清單上的項目。AI 回報做完了不算，清單全部打勾才算。

三個規矩都和 prompt 寫得好不好無關。prompt 決定每一步怎麼做，狀態決定每一步從哪裡開始、做完之後什麼才算數，流程越長，後者的份量就越重。

今天可以做的一件事

挑一件會分好幾次、跟 AI 一起完成的工作，準備兩份文件，一份是工作說明書，寫下這類工作每次都要照做的事，另一份是狀態卡。每次開新對話時把兩份一起交給 AI，結束時請它照下面的規則回覆。

開始之前，請先讀「工作說明書」與「狀態卡」，從狀態卡上「做到哪一步」接著做，不要重做已完成的部分。

結束時請輸出兩樣東西
1. 更新後的狀態卡
   - 「做到哪一步」與「依據在哪裡」可以直接更新
   - 「已經定案的事」不能修改，想調整請寫進「還懸著的事」並說明理由
   - 遇到工作說明書寫明要停下來確認的情況，先停下來並寫進「還懸著的事」
   - 「完成清單」全部打勾之前，不能回報工作完成
2. 建議收進工作說明書或記憶的事項
   - 只列出這次發現、以後每次都適用的做法或偏好
   - 由我決定要不要收進去，不要自行儲存

工作說明書
<貼上工作說明書>

狀態卡
<貼上目前的狀態卡>

第二項是讓人來決定什麼值得長期記住。工作說明書和記憶會影響之後的每一次對話，全部交給 AI 自己決定，很容易越記越雜，最後連自己都說不清 AI 為什麼會這樣做。

跑完一週之後填一句話。

如果這條流程現在斷掉，另一個人打開＿＿＿就知道做到哪一步，打開＿＿＿就知道這類工作該怎麼做。

兩個空格都填得出來，這條流程才算放到了對話外面。填不出來，代表狀態還留在某個人的腦袋或某一段對話裡。

留到明天的問題

狀態卡上有一條規則，已經定案的事只能由人寫入。這其實是一條權限規則，只是它管的是一份文件。流程再往前走，AI 碰到的就不只是一張狀態卡，它會讀信箱、改客戶資料、把簡報存進共用資料夾、替人把提案寄出去。

AI 做得到這些事的時候，該給它多少權限，又該由誰來決定？